1. Field of the Invention
The present invention relates, generally, to an improved data processing system and, more specifically, to a computer-implemented method for indicating a change in a service offering.
2. Description of the Related Art
A service-oriented architecture (SOA) allows applications and users to consume services provided by different parties. The consumption takes place in a loosely-coupled fashion, in which a binding between a service consumer and a service provider is through a service contract that a service provider advertises. The contract may be in the form of a web service definition language (WSDL, a specification for describing network services available from www.w3.org/TR/wsdl) file. Business users can support new business functions by orchestrating the use of services that have been provided by other parties.
An enterprise that implements a service-oriented architecture service may then provide services that might be reused, allowing new business processes to be implemented more easily.
However, a service-oriented architecture might also present governance issues, such as when service consumers need to know when any of the services being used have been changed. Some of the changes may be planned, such as version upgrades of the software providing the service. If these changes are properly communicated to service consumers, then it is possible for the service consumer to understand and react to those changes. Problems might occur when changes are not planned, or not accurately communicated to service consumers.
Scenarios where unplanned changes occur, or when changes are not accurately communicated to service consumers, might include when a new version of the software application has been loaded, and the version field in the service's web service definition language file is not accurately updated. Another example might be when a user or component has accidentally or deliberately overwritten the application with an incorrect version of the application. In yet another example, one of the resources used by the application has changed, causing the application (and the service it provides) to behave differently and possibly cause an unplanned change. For example, a Java EE Connector Architecture (JCA), (a generic, Java-based mechanism for connecting application servers and enterprise information systems (EIS) in an enterprise application integration (EAI) scenario) adapter used to connect to an enterprise requirement and planning system may have been downgraded to an older version. The downgrade may cause the application to retrieve a different set of values from the system than expected, and therefore deliver different data to service consumers.
Service consumers may also want to know when an application providing the service, or the server hosting the service, has been reset. The information might be useful in troubleshooting services, which may behave differently after an application or a server restart. This information is also useful in forensic investigations to investigate any irregularities in the service providers.
Previous solutions have attempted to declare changes to a service by publishing the service version number in the service's web service definition language file. The approaches focus on changes in declared service functionality and require developers or administrators to explicitly declare when new versions of a service are being provided. The current approaches rely on the developers and administrators and might have difficulty with timely updates, due to unintended changes or malicious attempts to change applications.